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1 Introduction 

The work presented in this paper constitutes a minor adaptation to a simplified set- 
ting, and a corresponding reformulation of the content of our [4|. We refer to that 
paper for further technical explanations of the formalism used below, for the jus- 
tification of terminology, as well as for more information concerning connections 
with previous workQ By highlighting results from J4| from a different perspective 
their relevance for understanding the methodological impact of the well-known re- 
cursive unsolvability of the halting problem, in which we firmly believe, becomes 
more apparent. Like [4] this paper focuses on the off-line halting problem, which 
unlike the on-line halting problem analyzed in |6] need not always give way to a 
diagonal argument. 

This paper concerns an investigation of issues relating to the halting problem 
perceived in terms of instruction sequences. Positioning Turing's result of J8] re- 
garding the recursive unsolvability of the halting problem as a result about pro- 



1 In |4) the focus is on modeling Turing machine computation, while in this paper the 
focus is on stack machines. In addition |4 | explains the semantics of instruction sequences 
via thread algebra (see |3 |) and in this paper we will use an operational semantics instead. 
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grams rather than machines, and taking instruction sequences as programs, we 
analyse the autosolvability requirement that a program of a certain kind must solve 
the halting problem for all programs of that kind. 

Below we will use the term execution both in connection with instructions 
and in connection with instruction sequences. This is not entirely consistent with 
1 1 1 where execution is given a rather confined meaning, involving the use of real 
computing devices. Here instruction sequences are mathematical objects and their 
execution, by necessity is merely a mathematical or logical model for the (real) 
putting into effect of (physical representations of) instruction sequences]! 

The paper follows the organization of [4|, beginning with a survey of the in- 
struction sequence notation that will be used used in this paper (Section|2]i. Next, 
we introduce services and a composition operator for services families (Section[3]). 
In Section|4]an operational semantics is provided for instruction sequences under 
execution in a context of service families. In Section [5] following [4|, we add two 
operators, named •, and ! , that are related to the processing of instructions by a 
service family. Then, as in H we propose to comply with conventions that ex- 
clude the use of terms that are not really intended to denote anything (Sections[6]). 
Thereafter, we introduce the concept of a functional unit and related concepts (Sec- 
tion[7ji. Then, we define autosolvability and related notions in terms of functional 
units related to stack machines (Section[8]). In Section[9]we specify a familiar menu 
of method names and operations on stacks. In Section[lO]we introduce the strong, 
intermediate, and weak Turing impossibility properties for programming environ- 
ments, equipped with a given and fixed way to encode instruction sequences into 
functional unit states. After that, we give positive and negative results concerning 
the autosolvability of the halting problem (SectionfTTI). In Section[T2]we provide a 
number of questions concerning Turing impossibility for stack machine program- 
ming. Finally, we make some concluding remarks (Section[T3l>. 

2 PGLB with Boolean Termination 

In this section, we introduce the program notation PGLBbt (PGLB with Boolean 
termination). In 0, a hierarchy of program notations rooted in program algebra 
is presented. One of the program notations that belong to this hierarchy is PGLB 
(ProGramming Language B). This program notation is close to existing assembly 
languages and has relative jump instructions. PGLBbt is PGLB extended with two 
termination instructions that allow for the execution of an instruction sequence 
to yield a Boolean value at termination. The extension makes it possible to deal 
naturally with instruction sequences that implement some test, which is relevant 
throughout the paper. 

In PGLBbt, it is assumed that a fixed but arbitrary non-empty finite set 21 of 
basic instructions has been given. The intuition is that the issuing of a basic in- 
struction in most instances effects the modification of a state and in all instances 

2 In fact execution as used in this paper corresponds to "directly putting into effect" as 
used in 1 1|. Instructions are said to be executed as well, or alternatively instructions are said 
to be issued, thus following a common terminology in computer architecture. 
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produces a reply at its completion. The possible replies are t (standing for true) 
and f (standing for false), and the actual reply is in most instances state-dependent. 
Therefore, successive executions of the same basic instruction may produce dif- 
ferent replies. 

PGLBbt has the following primitive instructions: 

- for each a G 21, a plain basic instruction a; 

- for each a £ 21, a positive test instruction +a; 

- for each a G 21, a negative test instruction —a; 

- for each / € N, a forward jump instruction #1; 

- for each Z <G N, a backward jump instruction 

- a plain termination instruction !; 

- a positive termination instruction !t; 

- a negative termination instruction !f. 

PGLBbt instruction sequences have the form u\ ; . . . ; u^, where u\ , . . . , u^ are prim- 
itive instructions of PGLBbt- 

In the process of executing a PGLBbt instruction sequence, these primitive 
instructions have the following effects: 

- the effect of a positive test instruction +a is that basic instruction a is executed 
and the execution proceeds with the next primitive instruction if t is produced 
and otherwise the next primitive instruction is skipped and the execution pro- 
ceeds with the primitive instruction following the skipped one - if there is no 
primitive instruction to proceed with, deadlock occurs; 

- the effect of a negative test instruction —a is the same as the effect of +a, but 
with the role of the value produced reversed; 

- the effect of a plain basic instruction a is the same as the effect of +a, but a 
run always proceeds as if t is produced; 

- the effect of a forward jump instruction #1 is that the execution proceeds with 
the I th next primitive instruction - if / equals or there is no primitive instruc- 
tions to proceed with, deadlock occurs; 

- the effect of a backward jump instruction \#Z is that the execution proceeds 
with the I th previous primitive instruction - if I equals or there is no primitive 
instruction to proceed with, deadlock occurs; 

- the effect of the plain termination instruction ! is that the execution terminates 
and in doing so does not deliver a value; 

- the effect of the positive termination instruction !t is that the execution termi- 
nates and in doing so delivers the Boolean value t; 

- the effect of the negative termination instruction !f is that the execution termi- 
nates and in doing so delivers the Boolean value f . 

A simple example of a PGLBbt instruction sequence is 

+a;#2;\#2;£;!t. 

When executing this instruction sequence, first the basic instruction a is issued 
repeatedly until its execution produces the reply t, next the basic instruction b is 
executed, and after that the run terminates with delivery of the value t. 
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From Section |7l we will use a restricted version of PGLBbt called PGLB s bt 
(PGLB with strict Boolean termination). The primitive instructions of PGLB s bt are 
the primitive instructions of PGLBbt with the exception of the plain termination in- 
struction. Thus, PGLB s bt instruction sequences are PGLBbt instruction sequences 
in which the plain termination instruction does not occur. 

We will write IS to denote the set of PGLBbt instruction sequences below. We 
will view this set of instruction sequences as a sort in a many-sorted algebra for 
which the sort name IS will be used. Further each PGLBbt instruction sequence is 
used as a constant of sort IS denoting itselfQ 

3 Services and Service Families 

In this section, we introduce service families and a composition operator for ser- 
vice families. We start by introducing services. 

It is assumed that a fixed but arbitrary non-empty finite set j$ of methods 
has been given. A service is able to process certain methods. The processing of a 
method may involve a change of the service. At completion of the processing of 
a method, the service produces a reply value. The set ffl of reply values is the set 
{t, f , d}. The reply value d stands for divergent. 

For example, a service may be able to process methods for pushing a natural 
number on a stack (push:n), testing whether the top of the stack equals a natural 
number (topeq:n), and popping the top element from the stack (pop). Execution 
of a pushing method or a popping method changes the service, because it changes 
the stack with which it deals, and produces the reply value t if no stack overflow 
or stack underflow occurs and f otherwise. Execution of a testing method does 
not change the service, because it does not changes the stack with which it deals, 
and produces the reply value t if the test succeeds and f otherwise. Attempted 
processing of a method that the service is not able to process changes the service 
into one that is not able to process any method and produces the reply d. 

In SF, the algebraic theory of service families introduced below, the following 
is assumed with respect to services: 

- a set 5? of services has been given together with: 

- for each m £ a total function 4- : 5? — > 5?; 

' am ' 

- for each m e a total function p m \5f^r£%\ 

satisfying the condition that there exists a unique S G with j-(S) = S and 
pm(S) = d for all m g 

When dealing with examples and applications we will assume that a suffi- 
ciently large collection of services is available and that a name is known for 
each of those. In addition for each name all equations that determine the graphs 
of -j- and p„, are available. 

- a signature Ly has been given that includes the following sort: 

- the sort S of services; 

3 This treatment of the sort IS is a shortcut of the presentation of |4| and |2| where the 
sort of threads is used as a behavioral abstraction of instruction sequences. 
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and the following constant and operators: 

- the empty service constant 8 : S; 

- for each m G the derived service operator 4- : S — » S; 

- 5^ and Hy are such that: 

- each service in 5? can be denoted by a closed term of sort S; 

- the constant 8 denotes the unique S G 5? such that -4-(S) = S and p m (S) = 
d for all m G jM\ 

- if closed term t denotes service S, then -4-(t) denotes service -r-(S). 

dm v * am v ' 

When a request is made to service S to process method nr. 

- if p m (S) 7^ d, then 5 processes m, produces the reply p m (S), and next proceeds 

- if p m (S) = d, then S is not able to process method m and proceeds as 8. 

The empty service 8 is the unique service that is unable to process any method. 

It is also assumed that a fixed but arbitrary non-empty finite set & of foci has 
been given. Foci play the role of names of services in the service family offered by 
an execution architecture. A service family is a set of named services where each 
name occurs only once. 

SF has the sorts, constants and operators in E,y and in addition the following 
sort: 

- the sort SF of service families; 

and the following constant and operators: 

- the empty service family constant : SF; 

- for each / G the unary singleton service family operator /. _ : S — > SF; 

- the binary service family composition operator _ © _ : SF x SF — >• SF; 

- for each F C the unary encapsulation operator dp : SF — » SF. 

We assume that there is a countably infinite set of variables of sort SF which 
includes u,v,w. Terms are built as usual in the many-sorted case (see e.g. 07)). 
We use prefix notation for the singleton service family operators and infix notation 
for the service family composition operator. 

The service family denoted by is the empty service family. The service family 
denoted by a closed term of the form f.H consists of one named service only, the 
service concerned is the service denoted by H, and the name of this service is /. 
The service family denoted by a closed term of the form C@D consists of all 
named services that belong to either the service family denoted by C or the service 
family denoted by D. In the case where a named service from the service family 
denoted by C and a named service from the service family denoted by D have 
the same name, they collapse to an empty service with the name concerned. The 
service family denoted by a closed term of the form df(C) consists of all named 
services with a name not in F that belong to the service family denoted by C. Thus, 
the service families denoted by closed terms of the forms f.H and (C) do not 
collapse to an empty service in service family composition. 
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Table 1 Axioms of SF 



u®% = u SFC1 
u®v=v®u SFC2 
(u®v)®w = u®{v®w) SFC3 
f.H®f.H' =f.8 SFC4 



d F {(b) = 
d F (f.H)=<b 
d F (f.H) = f.H 
d F (u®v) = d F (u)®d F (v) 



SFE1 

if / e F SFE2 
if / ^ F SFE3 
SFE4 



Table 2 Defining equations for the foci operation 

foci(0) = 

foci(/.ff) = {/} 

foci (u ® v) = foci (u) U foci (v) 



Using the singleton service family operators and the service family composi- 
tion operator, any finite number of possibly identical services can be brought to- 
gether in a service family provided that the services concerned are given different 
names. 

The empty service family constant and the encapsulation operators are primar- 
ily meant to axiomatize the operators that are introduced in Section|4] 

The axioms of SF are given in Table Q] In this table, / stands for an arbitrary 
focus from & and H and H' stand for arbitrary closed terms of sort S. The axioms 
of SF simply formalize the informal explanation given above. 

The foci operation foci defined by the equations in Table [2] (for foci / S & 
and terms H of sort S) provides the collection of foci that occur within a service 
family. Knowledge of this collection plays a role when defining the operational 
semantics of instruction sequences acting on a service family. The operation foci 
gives, for each service family, the set of all foci that serve as names of named 
services belonging to the service family. 

Given a service family C, if / ^ foci(C) then C can be written as d^{C'), and 
if / G foci (C) then C can be written as f.H U (C') for a suitable service H and 
an appropriate service family C' . 

4 Operational semantics 

For the set 21 of basic instructions, we take the set {f.m \ f £ JP,m g Let 
1 < i < k, and let p = u\ ; . . . ; u\ be a PGLBt, t instruction sequence, with basic 
instructions in 21, and for that reason a closed IS term and let C denote a service 
family and at the same time a closed SF term. Then a triple (i,p,C) can be read as 
the configuration consisting of p acting on service family C with program counter 
at value i when p is executed. Configurations are computational states but we will 
only use the term state for services and service families, and speak of a configura- 
tion if the instruction sequence is included as well as positional information about 
the instruction which is next to be issued, that is a program counter. 

From a non-terminal configuration (i,p,C), subsequent computational steps 
start with issuing the i th primitive instruction, i.e. it,-. By default, a run starts at the 
first primitive instruction. For technical reasons configurations with i = or i > k 
will be considered as well. 
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The operational semantics describes how a configuration can develop step by 
step into other configurations. Terminal configurations are configurations that sat- 
isfy any of the following conditions: 

- ui = !, or ui — !t, or m; = !f, or 

- i = or i > 0, or 

- U{ = f.m, or Ui = +f.m, or = —f.m for a focus / such that / ^ foci(C). 

If Ui — !, or Ui = !t, or m ; - = !f , then the configuration is correctly terminating. In 
all other cases the terminating configuration specifies an erroneous state indicating 
incorrect termination]^] 

The sequence of steps from a configuration is called a computation. Each step 
involves either the execution of a jump or the application of a method to a service. 
The service involved in the processing of a method is the service whose name is 
the focus of the basic instruction in question. After proceeding or more steps 
a computation can but need not end in a terminal configuration. If it ends in a 
terminal configuration the computation is said to converge, otherwise it proceeds 
forever and it is said to diverge. If the terminal configuration is correctly terminat- 
ing, the computation is said to be successful, otherwise the terminal configuration 
is incorrectly terminating and the computation is said to be unsuccessful. 

Computation steps for configurations are generated by the following four 
rules H 

Ui = #k 

1. 3 : 

„x fw-imp . , „. 
(i,p,C) ^ (i + k,p,C) 

Ui = \#k 

2 - u : 

[i,p,C) > (i-k,p,C) 

ut = f.m V (ui = +f.m A p m (H) = t) V (zt; = -f.m A p m (H) = f) 

3. r——r 

(i,p,f.H®d {f} (C)) (i+l,p,f.^H®d {f} (C))) 

(ut = +f.m A p m (H) = f ) V ( Ui = -f.m A p,„(H) = t) 

' (i,p,f.H®d {f] (C)) ( i + 2,p,f.^H®d m (C))) 

An instruction sequence may interact with the named services from the ser- 
vice family offered by an execution architecture. That is, during its executed an 
instruction sequence may issue a basic instruction for the purpose of requesting a 
named service to process a method and to return a reply value at completion of the 
processing of the method. 

4 Incorrect termination can be understood to represent the occurrence of an error during 
a computation. For instance execution of the instruction sequence #1;\#5; ! will lead to an 
error after the first instruction has been executed and for that reason the backward jump in 
the second instruction constitutes a fault in the instruction sequence. 

5 As usual, we write ( — j for the monus of i and j, i.e. i — j = i — j if ( > j and i — j — 
otherwise. 
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5 Apply and reply operators 

In this section, we combine the sort IS with the sort SF and extend the combina- 
tion with two operators, called apply operator and reply operator respectively, that 
relate to this kind of interaction between instruction sequences and services. 

The reply operator is concerned with the effects of service families on the 
Boolean values that computations possibly deliver at their termination. The reply 
operator does not always produce Boolean values: it produces special values in 
cases where no Boolean value is delivered at termination or no termination takes 
place. The apply operator determines the successive effect that basic instructions 
issued during a terminating execution have on a service family. The apply operator 
is made total by stipulating that it produces the empty service family in the case of 
diverging computations. 

Both operators mentioned above are concerned with the processing of methods 
by services from a service family in pursuance of basic instructions issued when 
an instruction sequence is executed. 

We will use in addition the following sort: 

- the sort R of replies; 

and the following constants and operators: 

- the reply constants t,f,d,m :R; 

- the binary apply operator _ • _ : IS x SF ->■ SF; 

- the binary reply operator _ ! _ : IS x SF ->■ R. 

We use infix notation for the apply and reply operators. 

The service family denoted by a closed term of the form p • C is the service 
family that results from processing the method of each basic instruction issued by 
the instruction sequence p by the service in the service family denoted by C with 
the focus of the basic instruction as its name if such a service exists. 

The value denoted by p ! C is the Boolean value serving as the flag of the 
termination instruction at which computation starting from the initial configuration 
(l,p,C) comes to a halt if that computation terminates correctly and in addition 
this termination instruction carries a Boolean value. 

The value m (standing for meaningless) is yielded if the computation termi- 
nates correctly ending with the program counter at a termination instruction not 
carrying a Boolean value, and the result is the value d (standing for divergent) if 
the computation does not correctly terminate. Formally the connection between 
computations and the apply and reply operators is as follows (again assuming that 
k is the number of instructions in p = u\ ; . . . ; u^): 

- if (1 ,p, C) produces a divergent computation then p»C = and p ! C = d . 

- if (l,p,C) produces an incorrectly terminating computation, say in some con- 
figuration (i,p,D) that satisfies one of these five conditions: i = 0, or i > k, 
or Ui = f.m, or = + f.m, or w; = —f.m for some basic instruction f.m (for 
which / ^ foci(D) must necessarily hold), then p»C — % and p ! C = d. 

- if (l,p,C) produces a correctly terminating computation, say ending in a con- 
figuration, (i,p,D) such that 1 < i < k, and either m; = !, or m,- = !t, or m,- = !f, 
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then p*C = D. Further in this case: if m ; - = ! then p ! C = m, if u, ■ = It then 
p ! C = t, and if u, = !f then p ! C = f. 

We write p 4 u iff p ! u = t or p I u — f or p I u = m. We write p 4b w iff /» ! u = t 
or p I m = f . 

6 Relevant Use Conventions 

In the setting of service families, sets of foci play the role of interfaces. The set of 
all foci that serve as names of named services in a service family is regarded as 
the interface of that service family. There are cases in which processing does not 
terminate or, even worse (because it is statically detectable), interfaces of services 
families do not match. In the case of non-termination, there is nothing that we in- 
tend to denote by a term of the form p • C or p ! C. In the case of non-matching 
services families, there is nothing that we intend to denote by a term of the form 
C@D. Moreover, in the case of termination without a Boolean reply, there is noth- 
ing that we intend to denote by a term of the form p ! C. 

We propose to comply with the following relevant use conventions: 

- p • C is only used if it is known that p 4 C; 

- p ! C is only used if it is known that p 4b C0 

- C®D is only used if it is known that foci (C) H foci (D) = 0. 

The condition found in the first convention is justified by the fact that x • u — 
if x u. We do not have x • u = only if x j" u. For instance, !t • = whereas 
!t 4 0. Similar remarks apply to the condition found in the second convention. 

The idea of relevant use conventions is taken from [5 1, where it plays a central 
role in an account of the way in which mathematicians usually deal with division 
by zero in mathematical texts. In the sequel, we will comply with the relevant use 
conventions described above. 

7 Functional Units 

In this section, we introduce the concept of a functional unit and related concepts. 

It is assumed that a non-empty finite or countably infinite set S of states has 
been given. As before, it is assumed that a non-empty finite set of methods has 
been given. However, in the setting of functional units, methods serve as names of 
operations on a state space. For that reason, the members of ^ will henceforth be 
called method names. 

6 If it turns out that in some case p ! C = f a failure has occurred because by using If p ! C 
the belief is implicitly assumed that p 4b C. A plausible cause for that state of affairs is an 
instruction sequencing fault. That is a mismatch between instruction sequencer intentions 
and the operational semantics of the instruction sequence that was constructed, for instance 
if at some place ! was written where !t was meant. Another plausible cause is that a mistake 
was made concerning the choice which instruction sequence from a library of given ones to 
execute. 
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A method operation on S is a total function from S to B x S. A partial method 
operation on S is a partial function from S to B x S. We write ^Kff(S) for the 
set of all method operations on S. We write M r and M e , where M G .# <?(S), 
for the unique functions : 5 -> B and E.S^S, respectively, such that M(s) = 
(R(s),E(s)) for allies. 

A functional unit for 5 is a finite subset of ^ x ^G{S) such that 
(m,M) G and (m,M') G JT implies M = M' . We write ,^W(S) for the set 
of all functional units for S. We write ^(Jf ), where e J^S), for the set 
{m£jf 3M G Jt0(S) • (m,M) G JT}. We write m^, where G &<%{S) and 
m G ^(Jf ), for the unique M G .£G{S) such that (m,M) G . 

We look upon the set Jijtf), where G ^W(S), as the interface of Jif . It 
looks to be convenient to have a notation for the restriction of a functional unit to 
a subset of its interface. We write {I,Jif), where G and / C J(3ttf), 

for the functional unit {(m,M) G \ m G /}. 

Let Jf G J^(S). Then an extension of is an M" G J^(S) such that 

,ye c jr. 

According to the definition of a functional unit, G (5). By that we have 
a unique functional unit with an empty interface, which is not very interesting 
in itself. However, when considering services that behave according to functional 
units, is exactly the functional unit according to which the empty service 8 (the 
service that is not able to process any method) behaves. 

We will use PGLB s b t instruction sequences to derive partial method operations 
from the method operations of a functional unit. We write Jzf (/./), where / C 
for the set of all PGLB s b t instruction sequences, taking the set {f.m \ m G /} as the 
set 21 of basic instructions. 

The derivation of partial method operations from the method operations of a 
functional unit involves services whose processing of methods amounts to replies 
and service changes according to corresponding method operations of the func- 
tional unit concerned. These services can be viewed as the behaviours of a ma- 
chine, on which the processing in question takes place, in its different states. 
We take the set &<&(S) x S as the set of services. We write Jf(s), where 
Jt? G .^^(S) and s G S, for the service (Jf,s). The functions ^ and p m are 
defined as follows: 



where s' is a fixed but arbitrary state in S. We assume that each J^(s) G 5? can 
be denoted by a closed term of sort S. In this connection, we use the following 
notational convention: for each Jrif (s) G S", we write Jf? (s) for an arbitrary closed 
term of sort S that denotes Jff (s). The ambiguity thus introduced could be ob- 
viated by decorating Jf(s) wherever it stands for a closed term. However, in this 
paper, it is always immediately clear from the context whether it stands for a closed 





if me J^(Jf) 
ifm^(Jf) , 
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term. Moreover, we believe that the decorations are more often than not distract- 
ing. Therefore, we leave it to the reader to make the decorations mentally wherever 
appropriate. 

Let ,ye G &W(S), and let / C J^(Jf). Then an instruction sequence x G 
_£f (/./) produces a partial method operation \x\$p as follows: 

\x\Ms) = (\x\ r ^(s)Ax\ e ^(s)) if \x\ r ^(s) =tV\x\ r jg,(s) =f , 
\x\jp (s) is undefined if \x\ r ^(s) = d , 

where 

\x\ r je ( S )=x\f.JP( S ), 

\x\ e ^(s) — the unique s' G S such thatx»/.^f (s) =f.Jf?(s') . 
If \x\jg> is total, then it is called a derived method operation of M '. 

8 Functional Units for Stack Machines 

In this section, we define some notions that have a bearing on the halting problem 
in the setting of PGLB s b t and functional units. The notions in question are defined 
in terms of functional units for the following state space: 

¥, = {0,1,:}* . 

The elements of T s can be understood as the possible contents of the tape of a 
stack whose alphabet is {0, 1 , :}. It is assumed that the top is the left-most element. 

The colon serves as a separator of bit sequences. This is for instance useful 
if the input of a program consists of another program and an input to the latter 
program, both encoded as a bit sequences. We could have taken any other tape 
alphabet whose cardinality is greater than one, but {0, 1,:} is quite handy when 
dealing with issues relating to the halting problem. 

Below, we will use a computable injective function a : T s — > N to encode the 
members of T s as natural numbers. Because T s is a countably infinite set, we as- 
sume that it is understood what is a computable function from T s to N. An obvious 
instance of a computable injective function a : T s — > N is the one where a{a\...a n ) 
is the natural number represented in the quaternary number-system by a\ . . .a n if 
the symbols 0, 1, and : are taken as digits representing the numbers 1, 2, and 3, 
respectively. 

A method operation M G ^(T,) is computable if there exist computable 
functions F,G:N->N such that Af(v) = (J3 (F(a(v))), a" 1 (G(a(v)))) for all vG 
T s , where a : T s — > N is a computable injection and j3 : N — >• B is inductively defined 
by J3 (0) = t and J3 (n + 1 ) = f . A functional unit G (T s ) is computable if, 
for each (m,M) G Jf, M is computable. 

It is assumed that, for each Jf? G ,^^/ (T. v ), a computable injective function 
from Jz? (f.<y( )) to {0, 1 }* with a computable image has been given that yields, 
for each x G -£f (/. y(Jf? )), an encoding of x as a bit sequence. If we consider the 
case where the jump lengths in jump instructions are character strings representing 
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the jump lengths in decimal notation and method names are character strings, such 
an encoding function can easily be obtained using the ASCII character-encoding. 

Although this may be of lesser generality than possible, we will assume that 
ASCII encoding is used thus removing a degree of freedom, and determining in 
detail how an implementation of instruction sequence programming over iff is 
supposed to work. 

We use the notation x to denote the encoding of x as a bit sequence. 

Let Jf G (T s ), and let / C (JT). Then: 

- x € ^f(f.J r (J^f)) produces a solution of the halting problem for Jzf(f.I) with 
respect to Jf? if: 

x|/.jr(v)forallveT, , 

x ! f.Jtf{y:v) =t&yl f.JP(v) for all y G &{fJ) and v G {0, 1 , :}* ; 

- x € &{f.<?{J%')) produces a reflexive solution of the halting problem for 
j£f (/./) with respect to if x produces a solution of the halting problem 
for Jgf (/./) with respect to and x G _Sf (/./); 

- the halting problem for _Sf (/./) with respect to is autosolvable if there 
exists an x G Jf(f.J r (J^)) such that x produces a reflexive solution of the 
halting problem for j£f (/./) with respect to ; 

- the halting problem for Jz? (/./) with respect to J^ 7 is potentially autosolvable if 
there exist an extension Jf?" of and the halting problem for ^f(f.J^(Jf')) 
with respect to Jff" is autosolvable; 

- the halting problem for Jzf(f.I) with respect to Jt? is potentially recursively 
autosolvable if there exist an extension Jt?" of and the halting problem for 
Jf(f.y(J$?')) with respect to 3tf" is autosolvable and 3tf" is computable. 

These definitions make clear that each combination of an ^ G (T s ) and an 
/ C ,J? (<?)?) gives rise to a halting problem instance. 

Below we will make use of a method operation Dup G 0(T S ) for duplicating 
bit sequences. This method operation is defined as follows: 

Dup(v) =(t,v:v) ifvG{0,l}*, 
Dup(v:w) = (t,v:v:w) if v G {0, 1}* . 

Proposition 1 Let Jif e ^^(T. s ) fee racft f/zaf (dup,Z) M p) G Jf 7 , /ef / C J^(Jf) 
fee smc/z //zaf dup G /, /ef x G _£f (/./), one/ Zef v G {0, 1}* a«<f w G {0, 1,:}* fee 
5mc/z f/zaf w = forw = v.w' for some w' G {0, 1,:}*. T/zen (/.dup;x) ! f.Jif (w) = 
x ! f.J?(v:w). 

Proof This follows immediately from the definition of Dup and the axioms for ! . 

□ 

The method operation Dup is a derived method operation of the above-mentioned 
functional unit whose method operations correspond to the basic steps that a Tur- 
ing machine with tape alphabet {0, 1 , :} can perform on its tape. This follows im- 
mediately from the computability of Dup and the universality of this functional 
unit. 
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Below we will make use of two simple transformations of PGLB s b t instruc- 
tion sequences that affect only their termination behaviour on and in particular the 
Boolean value yielded at termination in the case of termination. Here, we introduce 
notations for those transformations. 

Let x be a PGLB s b t instruction sequence. Then we write swap(x) for x with 
each occurrence of !t replaced by !f and each occurrence of !f replaced by !t, and 
we write f2d(x) for x with each occurrence of !f replaced by #0. In the following 
proposition, the most important properties relating to these transformations are 
stated. 

Proposition 2 Let x be a PGLB s bt instruction sequence. Then: 

1. if x ! u = t then swap(x) ! u = f and f2d(x) I u = t; 

2. ifx ! u — f then swap{x) ! u = t and f2d(x) ! u = d. 

The proof is an trivial adaptation of the elementary proof of the corresponding 
statement in the case of Turing Machine tapes, instead of Stack Machine data. 

9 Method names and method operations for a stack 

At this stage it is useful to lay down the names and meaning of the common meth- 
ods for stack manipulation. This can be done in many ways, and any choice will 
do. The interface I s consists of the following ten method names. These eight meth- 
ods are taken together in a functional unit ,¥£ s that represents a stack with this 
particular three symbol alphabet as a functional unit over T s . 

- empty leaves the state of the functional unit unchanged and returns t if the 
state represent and empty stack and f otherwise. 

- pop deletes the leftmost symbol, and returns reply t, if the stack is non-empty, 
otherwise it leaves the stack empty and returns f . 

- push:0, push:l and push:c insert respectively 0, 1 and : on the left-most posi- 
tion and each return f . 

- topeq:0, topeq:l, and topeq:c each test for the presence of a specific character 
at the top of the stack. If the stack is empty or its top differs from the symbol 
mentioned in the basic instruction name the reply is f, otherwise it is t. In all 
cases the stack is left unchanged. 

As mentioned above Dup is a method on stacks as well, but it is not included 
in the methods on 3P S . 

10 Turing Impossibility Properties 

The recursive unsolvability theorem by Turing is an impossibility result which 
may be found in many different circumstances. Looking at its proof that proof 
establishes the negation of potential autosolvability. Subsequently by combining 
it with the Church-Turing thesis that fact can be phrased in terms of recursive 
solvability in general. 
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As an impossibility result we take Turing's theorem to establish the impossibil- 
ity of a reflexive solution of the halting problem in any functional unit in J£"^ (T s ) 
extending JtfC . That state of affairs concerning a programming environment will be 
termed the (strong) Turing impossibility property. We formulate this only for func- 
tional units in (T s ) but it should be clear that these definitions can be adapted 
to many contexts that allow an encoding of programs (instruction sequences) into 
the state space upon which a program is acting when executed. Consider a func- 
tional unit JT G J^(T S ), and let / = J?(Jf). The pair (_Sf (/./), JT) consti- 
tutes an instruction sequence programming environment. For programming envi- 
ronments of this kind we introduce the following notions. 

- The programming environment has the strong Turing impossibility property 
if its halting problem is not potentially autosolvable. By default Turing Im- 
possibility refers to strong Turing impossibility if no further qualification is 
provided. 

- The programming environment has the intermediate Turing Impossibility 
Property if its halting problem is not potentially recursively autosolvable. 

- The programming environment has the weak Turing impossibility property if 
its halting problem is not autosolvable. 

It has been established in [4] and implicitly in (6) that the strong Turing im- 
possibility property holds for some programming environments where the halting 
problem is recursively solvable. This is an interesting situation because it com- 
bines the intuitions of two seemingly incompatible worlds: general computability 
on machines with an unbounded state space where Turing impossibility is taken 
for granted, and the computing devices that emerge from digitalized electrical en- 
gineering where everything is finite state and where for that reason all problems 
have computable solutions, however inefficient these solutions may be. 

We have no information about the existence of programing environments that 
have the intermediate Turing impossibility property but not the strong one and 
also not about the existence of programming environments that satisfy the weak 
Turing impossibility property and not the intermediate one. At this stage we have 
no indication that such examples will be of methodological importance for the 
theory of computer programming. 

11 Strong Turing impossibility in the presence of dup 

The following theorem tells us essentially that potential autosolvability of the halt- 
ing problem is precluded in the presence of the method operation Dup. 

Theorem 1 Let e &W(T S ) be such that (dup, Dup) e Jf, and let I C 

be such that dup G /. Then there does not exist an x £ J£(f .J? (Jt?)) such that x 

produces a reflexive solution of the halting problem for Jzf(f.I) with respect to 

Proof Assume the contrary. Let x S J*f(f.^(J{?)) be such that x produces a re- 
flexive solution of the halting problem for J>f (/./) with respect to JF, and let 
y = /.dup ;f2d(swap(xj). Then x \. f.J$°(y:y). By Proposition [2] it follows that 
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swap(x) 4- f.Jtf(y:y) and either swap(x) ! f.Jff(y:y) = t or swap(x) ! f.J^(y:y) = 
f. 

In the case where swap(x) ! / '.J$?(y:y) = t, we have by Proposition [2] that 
(i) f2d(swap{x)) ! f.Jtfty.y) = t and (ii) x ! f.Jf?(yy) = f. By Proposition [TJ 
it follows from (i) that (/.dup ;/2d(swap(x))) ! f.J(?(y) = t. Since y = /.dup ; 
f2d(swap(x)), we have y ! f.J4?(y) = t. On the other hand, because x produces 
a reflexive solution, it follows from (ii) that y f f.Jf?(y). This contradicts with 
y!/.JT(y)=t. 

In the case where swap(x) ! f.Jf(y:y) = f, we have by Proposition [2] that 
(i) /2tf(swap(*)) ! f.JP(y:y) = d and (ii) x ! f.Jfffyy) = t. By Proposition Q] 
it follows from (i) that (/.dup ;f2d(swap(x))) I f.Jf(y) = d. Since y = /.dup; 
f2d(swap(x)), we have y ! f.Jrf?(y) = d. On the other hand, because x produces 
a reflexive solution, it follows from (ii) that y J. f.J%?(y). This contradicts with 
y!/.^f(y)=d. □ 

It is easy to see that Theorem Q] goes through for all functional units for T s of 
which Dup is a derived method operation. 

Now, let = {(dup, Dup)}. By Theorem Q] the halting problem for 
Jz? (/.{dup}) with respect to is not (potentially) autosolvable. However, it is 
recursively solvable. 

Theorem 2 Let ,¥f = {(dup, Dup)}. Then the halting problem for ££ (/.{dup}) 
with respect to is decidable. 

Proof Let x G «5f (/.{dup}), and let x' be x with each occurrence of /.dup and 
+/.dup replaced by #1 and each occurrence of —/.dup replaced by #2. For all 
v 6 T s , Dup r (v) = t. Therefore, x | f.J^(v) Ox? 1 for all v G T,. Because x' is 
finite, x' J. is decidable. □ 



12 Open issues on Turing Impossibility properties for stack machine 
programming 

About Turing impossibility properties for stack machine programming we know 
in fact almost nothing except the result just proven that presence of dup implies 
the strong Turing impossibility property. 

Let JfJ result from J>f s by removing the method push:c. It follows from the 
results in [4 1 that this functional unit yields a programming system for which the 
halting problem is potentially recursively autosolvable. The difference made by 
the presence of this one method is quire remarkable. 

It is now easy to formulate several plausible questions which are open to the 
best of our knowledge. Indeed the objective of this lengthy paper is no more than 
to introduce the terminology of Turing impossibility properties and to state these 
problems in full detail. Let J4? s dup denote the extension of J^ s with the method 
dup. I St dup is its interface. 

1. Is the halting problem for J£(f.I s j up )) w.r.t. M's^up recursively solvable 'fl 

A simpler but equally interesting problem results if the action pushx is removed from 
3%4up and from h,dup- 
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2. If so, can <ffis : d u p be extended with methods that are not derivable from J^^p 
without destroying recursive solvability of the halting problem? 

3. Does the programming system Jz?(/./ s )) with ,yf s feature the weak Turing im- 
possibility property? 

4. If so, what about the intermediate and strong Turing impossibility properties? 

Some remarks concerning the motivation of there questions is in order. To be- 
gin with, the virtue of separating Turing impossibility from recursive unsolvability 
is that the technical content of the recursive unsolvability proof for the Halting 
problem is made independent from the Church-Turing thesis. However convinc- 
ing that thesis may be, unquestionably it is strongly connected with general com- 
putability theory on the infinite set of natural numbers. As a conceptual toolkit for 
understanding the practice of computation recursion theory on the natural numbers 
can be questioned, however. 

Phrasing the halting problem in terms of program machine interaction, rather 
than exclusively in terms of machines correlates with the fact that the intuition 
of computing on an unbounded platform has been so successful for the develop- 
ment and deployment of high level program notations. Much more so than for the 
area computer architecture which always keeps the underlying electric circuitry in 
mind, and for which the digital perspective means that an abstraction can be made 
from infinite state machines in need of a probabilistic analysis to finite state ma- 
chines that can be understood, at least in principle, without the use of probabilities. 

13 Concluding Remarks 

We have put forward three flavors of the Turing impossibility property: strong, 
intermediate and weak. These notions have been applied to stack machine pro- 
gramming. Some results concerning that case have been translated from the work 
on Turing machines in [4|, and several open questions have been formulated. 

Programming environments which satisfy the strong Turing impossibility 
property and for which the halting problem is recursively solvable at the same 
time constitute an interesting bridge between the two worlds of computer science: 
general computation without bounds on memory and time, and finite state compu- 
tation in bounded time. The existence of these combined circumstances depends on 
being specific on how the encoding of instruction sequences into data is achieved. 
The classical Turing impossibility property for a Turing complete programming 
environment is not dependent on the specific way in which that encoding is done, 
in that sense the classical approach is more general. 
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